-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Add Trino 478 release note #26726
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Trino 478 release note #26726
Conversation
7ba941a to
64e2c9c
Compare
|
@ebyhr I've added two more entries |
e51817f to
76113ca
Compare
72cb5a4 to
f11e381
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds the release notes for Trino version 478, documenting new features, bug fixes, and improvements across various components and connectors.
- Creates a comprehensive release notes document for version 478 with changes across general functionality, web UI, Docker, and multiple connectors
- Adds the new release notes file to the documentation index to make it accessible
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/src/main/sphinx/release/release-478.md | New release notes document containing features and fixes for Trino 478 |
| docs/src/main/sphinx/release.md | Updated table of contents to include the new release-478 entry |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| @@ -0,0 +1,106 @@ | |||
| # Release 478 (dd Oct 2025) | |||
Copilot
AI
Oct 4, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The release date placeholder 'dd Oct 2025' should be replaced with the actual release date.
| # Release 478 (dd Oct 2025) | |
| # Release 478 (3 Jun 2024) |
60a2313 to
57aaf2c
Compare
b011102 to
7299817
Compare
|
|
||
| ## Docker image | ||
|
|
||
| * Run Trino on JDK 25.0.0 (build 36). ({issue}`26693`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: This will change to 25.0.1 soon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we treating this as user visible? Because we support attaching external plugins to Trino run from official docker image?
fc92c59 to
56b8440
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of changes and final clean up needed
f2013f8 to
04c1acc
Compare
Co-Authored-By: Cole Bowden <[email protected]>
b06fbfb to
412d267
Compare
Reviewer's GuideThis PR integrates the Trino 478 release notes into the documentation by updating the Sphinx toctree and adding a new release page with categorized change entries. Flow diagram for Trino 478 release note integrationflowchart TD
A["Update Sphinx toctree in release.md"] --> B["Add release/release-478 to toctree"]
B --> C["Create release/release-478.md with categorized release notes"]
C --> D["Documentation includes Trino 478 release notes"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `docs/src/main/sphinx/release/release-478.md:16-17` </location>
<code_context>
+* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically.
+ way. ({issue}`26938`)
</code_context>
<issue_to_address>
**issue (typo):** Remove the extraneous 'way.' fragment at the end of the sentence.
'way.' is likely a typo and should be deleted to improve clarity.
```suggestion
* Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically. ({issue}`26938`)
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
FYI, i changed the target branch of this PR
|
|
Very funny (and unhelpful) that Copilot is randomly suggesting different PR numbers. |
|
@colebow thanks for noticing! BTW Whenever you see a bot's comment, like these copilot's, that you verified to be unhelpful, please resolve them (ideally along with thumb down reaction, but at least resolve) |
| * Add `retry-policy.allowed` configuration property to specify which retry | ||
| policies can be selected by the user. ({issue}`26628`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Add `retry-policy.allowed` configuration property to specify which retry | |
| policies can be selected by the user. ({issue}`26628`) | |
| * Add `retry-policy.allowed` configuration property to specify which query retry | |
| policies can be selected by the user. ({issue}`26628`) |
| * Add `retry-policy.allowed` configuration property to specify which retry | ||
| policies can be selected by the user. ({issue}`26628`) | ||
| * Add support for loading plugins from multiple directories. ({issue}`26855`) | ||
| * Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`) | |
| * Add the `/v1/integrations/gateway` endpoint that exposes additional cluster metrics for Trino Gateway. ({issue}`26548`) |
| policies can be selected by the user. ({issue}`26628`) | ||
| * Add support for loading plugins from multiple directories. ({issue}`26855`) | ||
| * Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`) | ||
| * Allow dropping an uninitialized catalog that failed to load. ({issue}`26918`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to quantify this with "When using dynamic catalogs" or similar?
* When using dynamic catalogs, allow dropping ...
| * Add support for loading plugins from multiple directories. ({issue}`26855`) | ||
| * Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`) | ||
| * Allow dropping an uninitialized catalog that failed to load. ({issue}`26918`) | ||
| * Improve performance of queries with an `ORDER BY` clause. ({issue}`26725`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Improve performance of queries with an `ORDER BY` clause. ({issue}`26725`) | |
| * Improve performance of queries with an `ORDER BY` clause using `varchar` or `varbinary` types. ({issue}`26725`) |
| * Improve performance of queries with joins which spill to disk. ({issue}`26076`) | ||
| * Fix potential incorrect results when reading `row` type. ({issue}`26806`) | ||
| * Return all catalogs, including uninitialized ones, for queries from `metadata.catalogs`. ({issue}`26918`) | ||
| * Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically. ({issue}`26938`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
this is a bug fix, so it's best to start with "Fix"
| * Ensure that queries with and without `EXPLAIN ANALYZE` are planned identically. ({issue}`26938`) | |
| * Fix `EXPLAIN ANALYZE` planning so that it executes with the same plan as would be used to execute the query being analyzed. ({issue}`26938`) |
| * Propagate `queryId` to [Open Policy Agent](/security/opa-access-control) | ||
| authorizer. ({issue}`26851`) | ||
|
|
||
| ## Web UI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs say "The Preview Web UI is not suitable for production usage, and only available for testing and evaluation purposes."
Thus, any changes in that component are irrelevant from end user / trino operator standpoint. Release notes are for end users' and operators' consumption.
Let's remove all entries pertaining the preview web ui
|
|
||
| ## Delta Lake connector | ||
|
|
||
| * Fix failure when reading `map` type with value type is `json` and value is `NULL`. ({issue}`26700`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * Fix failure when reading `map` type with value type is `json` and value is `NULL`. ({issue}`26700`) | |
| * Fix failure when reading `map` type with `json` value type when a value is `NULL`. ({issue}`26700`) |
| * Add support for reading encrypted Parquet files. ({issue}`24517`, {issue}`9383`) | ||
| * Deprecate the `gcs.use-access-token` configuration property. Use `gcs.auth-type` instead. ({issue}`26681`) | ||
| * Improve performance of queries using complex predicates on `$path` column. ({issue}`27000`) | ||
| * Prevent writing invalid dates and timestamps before `1582-10-15` by the ORC writer. ({issue}`26507`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a bug fix
| * Prevent writing invalid dates and timestamps before `1582-10-15` by the ORC writer. ({issue}`26507`) | |
| * Fix writing invalid dates and timestamps before `1582-10-15` when writing ORC files by setting calendar type in the file footer. Previously, Trino did not set the calendar type in the file footer, and values before `1582-10-15` could be read incorrectly by other query engines such as Apache Hive. ({issue}`26507`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marcinsbd @raunaqmorarka does this apply to Iceberg connector too?
|
|
||
| * Improve performance when writing sorted tables and `iceberg.sorted-writing.local-staging-path` | ||
| is set. ({issue}`24376`) | ||
| * Return execution metrics while running the `remove_orphan_files` procedure. ({issue}`26661`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's not "procedure". The code calls this "table procedure"
But the docs calls it "command" https://trino.io/docs/current/connector/iceberg.html#remove-orphan-files
| * Return execution metrics while running the `remove_orphan_files` procedure. ({issue}`26661`) | |
| * Return execution metrics while running the `remove_orphan_files` command. ({issue}`26661`) |
|
|
||
| ## SPI | ||
|
|
||
| * Require `shutdown` to be implemented by the `Connector`. ({issue}`26718`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Connector is the name of the interface connectors implement.
The interface does not implement shutdown. Quite contrary, it lost its default implementation.
| * Require `shutdown` to be implemented by the `Connector`. ({issue}`26718`) | |
| * Remove default implementation from `Connector.shutdown()`. ({issue}`26718`) |
| * Add `retry-policy.allowed` configuration property to specify which retry | ||
| policies can be selected by the user. ({issue}`26628`) | ||
| * Add support for loading plugins from multiple directories. ({issue}`26855`) | ||
| * Add the `/v1/integrations/gateway` endpoint for integration with Trino Gateway. ({issue}`26548`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW I am not convinced we should have added that.
Trino and Trino Gateway are both projects we manage, so we can have coupling between them. That does not mean we should or want such coupling. Everything is a trade off, of course. If this endpoint exposes information previously unavailable, and also interesting to Trino Gateway only, we perhaps want to have it. But it doesn't look like this is the case here. The endpoint exposes cluster utilization metrics (memory, load), which are generally useful for observability and also for any other query routing logic. We should expose them in gateway-agnostic manner, rather than build a public-but-do-not-use-kind-of-internal-yet-public API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've discussed that already and settled on the decision that it's ok to have a client specific endpoint (like we have for the UI). We can revisit this decision but if it blocks the release we should just revert the change and move on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok to have a client specific endpoint (like we have for the UI)
UI is not the best example, because it's maintained within this repo. The UI endpoints can change as the UI needs evolve.
This new endpoint is different. It's meant for the Trino Gateway, so in theory it should not be used by any other software. Any other query routing software will needs its own endpoint, which is quite undesirable. All this while the information exposed is no way trino gateway specific and could be exposed in a more reusable manner.
We can revisit this decision but if it blocks the release we should just revert the change and move on
Agreed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you that it's undesirable to have an endpoint for each service and it should be in a reusable manner
IMO, the coupling between Trino Gateway and Trino is inevitable. If Trino changes, Trino Gateway will need to change. For example, in this PR because Trino 477 removed some of the jmx stats, which caused Trino Gateway to fail, we had to pin Trino version to 476 and look for workarounds.
For this endpoint specifically, yes the data it returns can be useful for other software as well and should be gateway-agnostic. But I think the point is that each software should deserve its own dedicated endpoint so that they are not affected by unintentional changes. Other software owners are welcome, of course, to use this endpoint, but it is their responsibility to make sure their software doesn't break at all times, even after we roll out new changes to this endpoint. It's another way of saying there's no SLA on this endpoint if they use it, whereas if we create a generic endpoint, there's implied SLA
At the end of the day, if other query routing logic software needs similar data to be returned, they will likely end up with similar code in their endpoint. Yes this results in duplicate code. But we can look into how to extract common logic to a helper function. At that point, maybe we will find some discrepancies in these seemingly-similar looking endpoints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I think the point is that each software should deserve its own dedicated endpoint so that they are not affected by unintentional changes.
I appreciate the openness but I doubt that would be want we would actually want to maintain in the project.
BTW trino already exports tons of metrics in standard format (that's why jmx became obsolete), so i don't quite yet understand why we need dedicated endpoints just for selected metrics useful for selected use case
212e26e to
a0d9b10
Compare
it's how i saw it working many times, but this time it did not work. |
|
unfortunately it is not possible to reopen this PR, even after i recreated the base branch i will go over recent comments and apply them as separate fixup there. |
Description
Assemble the release notes for the upcoming Trino 478 release.
Additional context and related issues
See https://github.com/trinodb/trino/pulls?q=is%3Apr+is%3Aclosed+milestone%3A478
Release notes
(x) This is not user-visible or is docs only, and no release notes are required.
Verification for each pull request
Format: PR/issue number, ✅ / ❌ rn ✅ / ❌ docs
✅ rn - release note added and verified, or assessed to be not necessary, set to ❌ rn before completion
✅ docs - need for docs assessed and merged, or assessed to be not necessary, set to ❌ docs before completion
25 Sep 2025
VendedCredentialswithFileSystemCredentials#26699 ✅ rn ✅ docs26 Sep 2025
28 Sep 2025
29 Sep 2025
30 Sep 2025
01 Oct 2025
02 Oct 2025
03 Oct 2025
04 Oct 2025
05 Oct 2025
06 Oct 2025
07 Oct 2025
08 Oct 2025
09 Oct 2025
plugin.dir#26855 ✅ rn ✅ docs10 Oct 2025
12 Oct 2025
13 Oct 2025
14 Oct 2025
gcs.auth-typeconfiguration #26681 ✅ rn ✅ docs15 Oct 2025
TestIcebergS3TablesConnectorSmokeTest.testSelectInformationSchemaTables#26958 ✅ rn ✅ docs16 Oct 2025
17 Oct 2025
18 Oct 2025
NativeLogicalTypesAvroTypeManager#validateLogicalType#27009 ✅ rn ✅ docs20 Oct 2025
21 Oct 2025
22 Oct 2025
23 Oct 2025
24 Oct 2025
ciworkflow onmaster#27094 ✅ rn ✅ docsSummary by Sourcery
Add the Sphinx release notes page for Trino version 478 and register it in the documentation toctree.
Documentation: